Downloading file reception process

ABSTRACT

An audiovisual data reproduction device includes a connection to a central server configured to distribute files to the device. Reception functions associated with a respective type of data are provided to the device The device is configured to: select an available storage area of a specified minimum size, open a reception file on the audiovisual data reproduction device in the selected available storage area, receive each packet of a file sent by the server and write each packet sent to the reception file (with each file including information representative of a type of data associated with the file), and for each file received, search for a respective reception function associated with each received file based on the information representative of the type of data associated with the file. Each reception function is configured to process associated received files and update the device according to the data included therein.

CROSS REFERENCES TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 13/872,534filed Apr. 29, 2013 which is a continuation of application Ser. No.13/164,258 filed Jun. 20, 2011 (now U.S. Pat. No. 8,495,109 issued Jul.23, 2013), which is a continuation of application Ser. No. 09/583,863filed Jun. 1, 2000 (now U.S. Pat. No. 7,992,178 issued Aug. 2, 2011),which claims priority to French Application No. 00 01907 filed Feb. 16,2000, the entire contents of each of which are hereby incorporated byreference in this application.

FIELD OF THE INVENTION

The present invention relates to a file reception process applied to anaudiovisual data reproduction system.

BACKGROUND OF THE INVENTION

In the prior art, file reception processes comprising a first step,wherein the file(s) received are stored in memory in a file located in atemporary storage area, are known. Then a specific procedure checkswhether the file(s) received correspond to the file(s) expected. If thisis the case, according to the type of file, the files received arecopied to a specified permanent storage area.

OBJECTS AND SUMMARY OF THE INVENTION

Therefore, the purpose of the present invention is to remedy thedisadvantages of the prior art by proposing a file reception process nolonger requiring temporary file storage.

This purpose is achieved by a process for receiving files sent by acentral server an audiovisual data reproduction system, managed by anoperating system and linked to the server, by means of a data transferlink, characterized in that the process comprises: a step consisting ofinitializing a link between the central server and an audiovisual datareproduction system, a step consisting of storing files sent by thecentral server on storage means of the audiovisual data reproductionsystem, each file comprising specified information representative of thetype of data contained in the file, a step consisting of searching, foreach file received, a specific reception function, this search stepbeing carried out by means of the specified information representativeof the type of data contained in the file, a step consisting ofprocessing each file by the corresponding reception function, theprocessing comprising copying of the file received to a specifiedstorage area.

BRIEF DESCRIPTION OF DRAWINGS

The invention, with its characteristics and advantages, will beunderstood more clearly upon reading the description given withreference to the appended drawings, wherein:

FIG. 1 represents a logic diagram of the file reception processaccording to the invention,

FIG. 2 represents a logic diagram of representative song file receptionfunction,

FIG. 3 represents a logic diagram of a representative album cover filereception function.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The file reception process according to the invention is implemented byan audiovisual data reproduction system such as that described in theEuropean patent application No. 99 401 785.3. According to this Europeanpatent application, the reproduction system essentially comprises acentral processing unit managing, by means of a plurality of interfacesand an operating system, sound reproduction, image display, songselection and a link with a remote audiovisual data distribution server.The operating system is organized in hierarchical modules each managinga specific function of the audiovisual data reproduction system.

The operating system of such an audiovisual data reproduction systemalso manages a database. This database contains data on the files storedon the reproduction system's storage means. These files particularlyrepresent, either digitized data forming songs, or graphic datarepresenting the cover of the albums from which the songs are taken, oranimations (video or advertising). For example, there are at least twotypes of graphic files. The first type of graphic file represents thealbum cover in a small format. This first type of graphic file is usedduring a customer's search in the list of songs available on thereproduction system. The second type of files represents the album coverin a large format. This second type of file is used when the customerhas selected a song taken from the album corresponding to the cover. Thethird type of file may be a video, advertisement or survey. Thedifferent file types, song files, graphic files of the first and secondtypes, are differentiated using a different file extension for each filetype.

The data contained in the database is used to determine the linksexisting between the song files and the associated graphic files, suchthat all song files are linked to at least one graphic file. However,graphic files representing the album cover may not be linked to any songfile. This means that the songs in the album represented by the coverare not stored on the reproduction system but may be ordered in order tobe downloaded onto the reproduction system's storage means. Similarly,new songs with their corresponding album sleeve may be ordered in orderto be downloaded onto the reproduction system's storage means. It isduring the downloading of the files corresponding to the songs or albumsleeves that the process according to the invention is implemented.

When new songs are ordered using an audiovisual data reproductionsystem, the operating system of the reproduction system checks whether,for the new song, a graphic file, representing the album cover, isalready stored on the storage means. If this is not the case, thecorresponding graphic file(s) is/are also ordered. For each fileordered, a function intended to process and handle the file ordered iscreated by a module of the operating system supervising the type of fileordered. In this way, the operating system comprises a first modulemanaging song files, a second module managing the first type of graphicfiles, a third module managing the second type of graphic file and othermodules managing the other file types. In the rest of this document, theoperation will be described with three different file types. However,this does not represent a limitation of the present invention. In thisway, during the order, for example of a specified song file, the firstmodule creates a specific reception function for the song files ordered.To do this, the database comprises the name of all the files of all thesongs available on the reproduction system and the name of all the filesof all the downloadable songs. In this way, for each file ordered, thereception function is created.

Similarly, the first, second and third modules comprise a functioncreating a “standard” reception function used to account for thereception of a song file or a graphic file of the first or second type.In this way, even if a file, e.g. a song file, was not ordered directlyby means of the reproduction system, but by other means such as, forexample, the server or an Internet site connected to the server, thereception of this file may be taken into account by the reproductionsystem.

When the order of a file has been validated, a fourth module of theoperating system handles the management of the link with the remoteserver. For this, as soon as a communication is connected with theserver, the fourth module creates a specific file comprising theidentification of all the files ordered on the reproduction system.After the server checks any rights authorizing the downloading of filesonto the reproduction system or not, the requested files are sent to therequesting reproduction system. The files are sent in data packets.

FIG. 1 represents a logic diagram of the file reception processaccording to the invention. In the process according to the invention, afirst step 10 consists of initializing the communication between theserver and the reproduction system to perform the file transfer. Then,the process comprises a step 11 consisting of opening a reception fileon the storage means. According to the invention, the storage areaselected is a permanent storage area wherein the memory available has aspecified minimum size. In this way, unlike the prior art, the data isnot stored in a specific temporary storage area, but in any area of thestorage means, provided that this area has a specified minimum size.After the file has been opened, during a third step 12, a“telecommunication” module of the operating system, is set to standbyfor a data packet.

Then, during a reception step 13, the data contained in the packetreceived is copied to the open file. A checking step 14 checks whetherthe packet that has just been copied is the last packet of the filebeing received. As long as the last packet of the file being receivedhas not been received, all the data packets of same file are copied tothe previously opened file. When the last data packet of the file isdetected during the checking step 14, the operating systemtelecommunication module creates, during a sixth step 15, a notificationthat it then sends to the fourth module managing the link with theserver. This notification informs the fourth module that a new file hasbeen received. As soon as this notification is received, the fourthmodule switches from a standby step 20 to a search step 21 in all thereception functions created, to find whether any of them relate to thefile received. Similarly, the fourth module also searches to findwhether a standard reception function exists.

The search is carried out by means of the name of the file receivedand/or by means of its extension. Indeed, each reception function isspecific, either to a specific file or to a file type. Consequently,using the name or extension of the file received, the associatedreception function can easily be located by the fourth module. When thefourth module locates the function corresponding to the file received,it is then activated during a ninth step 22 to start the processing ofthis new file. For each file related to a song, a first receptionfunction is activated during a tenth step 24, and for each file relatedto an image, a second reception function is activated during an eleventhstep 23. The processing of a song file or image file essentiallyconsists of copying the file received to an appropriate memory area andthen updating the reproduction system's database. If no receptionfunction is located by the fourth module of the reproduction system, theprocess is stopped and no other action or operation is carried out onthe file received.

FIG. 2 represents the logic diagram of a representative song filereception function. In a first step 30, the reception function checks inthe reproduction system's database whether the file already exists. Ifit exists, the new file copied over the old one in a second step 31,such that the old file is deleted, if the file does not exist, the newfile is stored in memory, in a third step 32, to an appropriate area ofthe storage means, e.g. to a specific directory. Then, the functionchecks, in a fourth step 33, whether the new file was copied correctly.If this is not the case, the function, in a fifth step 302, deletes thefile received. If the new file was copied correctly, the receptionfunction updates the database. This update comprises, in a sixth step34, a search in the file received, for the data to update the database.Then, using the data found, the reception function checks, in a seventhstep 35, that the associated graphic files exist. Similarly, thereception function checks whether the versions of the song file andassociated graphic files are compatible with each other and with theoperating system version. Otherwise, the operating system is not updatedor the new graphic files are ordered, for example, according to theprocess described in the European patent request No. 99 401 785.3.

Then, in an eighth step 36, the reception function updates the databaseto account for the associated graphic files. In a ninth step 37, thereception function adds to an event table in the reproduction system'sdatabase that a new song file has been received.

In a tenth step 38, the reception function updates a file stored on thereproduction system, comprising the identification of all the songsavailable on the reproduction system. Each song is, for example,identified by means of a single number. This file is used by the serverto detect the list of songs available on each reproduction systemconnected to the server. In this way, the server can detect the list ofsongs present on the reproduction system by requesting, duringcommunication with the reproduction system, the latter to send the filecontaining the list of songs. In this way, the server simply needs toextract the song numbers contained in this file to find out the songsavailable on the reproduction system.

In an eleventh step 39, the reception function adds an entry to astatistics table in the reproduction systems database. This statisticstable makes it possible to determine how many times the songcorresponding to the new file received is selected. In a twelfth step301, the reception function updates a purchase table in the reproductionsystem's database. This purchase table is used, for example, to checkthat the number of songs ordered is less than a specified number or tobill the songs ordered. Then, the reception function carries out thefifth step 302 consisting of deleting the file received at its originallocation. Indeed, the file received in the second 31 or third step iscopied to a specified memory area. Consequently, the file received iskept in its initial location throughout the database update steps. Afterthis update, the initial version is of no further use and, consequently,may be deleted. The reception function ends with a thirteenth step 303consisting of updating the number of songs that can be selected by acustomer on the reproduction system. This number is stored in memory onthe system. storage means to be compared to a specified threshold. Whenthe number is equal to the threshold, this means that the reproductionsystem comprises a maximum number of songs that can be selected and thatit therefore not possible to order others without deleting at least onesong beforehand.

FIG. 3 represents the logic diagram of a representative album cover filereception function. According to the invention, the processing ofgraphic files of the first and second types is identical. The graphicfile reception function checks, in a first step 40, the integrity of thefile received. In a second step 41, the reception function checks in thereproduction system's database whether the graphic file already exists.If it exists, the new file is copied, during a third step 42, over theold file, such that the old file is deleted. If the file does not exist,the new graphic file is copied, during a fourth step 43, in anappropriate area of the storage means, e.g. to a specific directory.Then, the function checks, to a fifth step 44, whether the new file wascopied correctly. If this is not the case, the function, in a sixth step46, deletes the file received. If the new file was copied correctly, thereception function, in a seventh step 45, updates the database. Thisupdate consists of indicating the name of the new graphic file, and thesongs to which it is linked, i.e. the songs belonging to the albumrepresented by the graphic file. All this data is either available inthe graphic file or available in an archive table in the database.

In this way, the file reception process according to the invention ischaracterized in that it comprises: a step consisting of initializing alink between the central server and an audiovisual data reproductionsystem, a step consisting of storing files sent by the central server onstorage means of the audiovisual data reproduction system, each filecomprising specified information representative of the type of datacontained in the file, a step consisting of searching, for each filereceived, a specific reception function, this search step being carriedout by means of the specified information representative of the type ofdata contained in the file, a step consisting of processing each file bythe corresponding reception function, the processing comprising copyingof the file received to a specified storage area.

In another embodiment, the storage step consists of opening a file inany permanent memory area with an available area of a specified minimumvalue, to write the data sent.

In another embodiment, the processing step comprises the update of adatabase of the audiovisual data reproduction system to account for thedata contained in the file received.

In another embodiment, the search step is activated when the last datapacket corresponding to a whole file is stored in memory.

In another embodiment, the specified information comprises the fileextension and/or the name of the file received.

In another embodiment, when the specified information represents a songfile, the database update step comprises at least one of the followingsteps: a step consisting of checking the compatibility of the version ofthe song file with the version of the reproduction system operatingsystem, a step consisting of updating a file stored on the reproductionsystem containing the identification of all the songs stored on thereproduction system, a step consisting of updating a statistics table inthe database making it possible to determine the selection frequency ofthe song corresponding to the file stored in memory, a step consistingof updating purchase table containing the number and name of all thesongs purchased for the reproduction system, a step consisting ofupdating a counter of songs that can be selected to check that thenumber of songs that can be selected is not greater than a specifiedthreshold.

It must be clear for those experienced in the art that the presentinvention enables embodiments in many other specific forms withoutleaving the field of the invention as claimed. Consequently, the presentembodiments must be considered as illustrations, but may be modified inthe field defined by the scope of the claims attached, and the inventionmust not be limited to the details given above.

What is claimed is:
 1. An audiovisual data reproduction device,comprising: a network connection to a server, the server beingconfigured to distribute files to the audiovisual data reproductiondevice; an operating system configured to manage the audiovisual datareproduction device; a storage medium; and a plurality of receptionfunctions, each said reception function being associated with arespective type of data; wherein the audiovisual data reproductiondevice is configured to: create files in available storage areas of thestorage medium to store files sent by the server, at least some of thefiles sent by the server indicating types of data associated with therespective files, and for the files sent by the server that indicate thetypes of data associated with the respective files, search forrespective reception functions based at least in part on respectiveindicated types, wherein each said reception function is configured toprocess associated files that have been received and cause theaudiovisual reproduction device to be updated according to data includedin the processed received file.
 2. The audiovisual data reproductiondevice of claim 1, wherein indications of the types of data in the filessent from the server are indicated by respective file extensions.
 3. Theaudiovisual data reproduction device of claim 1, wherein indications ofthe types of data in the files sent from the server are indicated byrespective names of the files.
 4. The audiovisual data reproductiondevice of claim 1, wherein indications of the types of data in at leastsome of the files sent from the server correspond to song files, and therespective reception function causes a song database stored on theaudiovisual data reproduction device to be updated.
 5. The audiovisualdata reproduction device of claim 4, wherein the song database stored onthe audiovisual data reproduction device is updated by associatingreceived song files with graphical files stored in the audiovisualreproduction device.
 6. The audiovisual data reproduction device ofclaim 1, wherein indications of the types of data in at least some ofthe files sent from the server correspond to song files, and therespective reception function causes a compatibility check betweenversions of the song files received and a version of the operatingsystem of the audiovisual data reproduction device.
 7. The audiovisualdata reproduction device of claim 1, wherein indications of the types ofdata in at least some of the files sent from the server correspond tosong files, and the respective reception function causes an update to astatistics table used in determining selection frequencies of the songscorresponding to the files.
 8. The audiovisual data reproduction deviceof claim 1, wherein indications of the types of data in at least some ofthe files sent from the server correspond to song files, and therespective reception function causes an update to a purchase tableincluding numbers and names of all songs purchased for the audiovisualdata reproduction device.
 9. The audiovisual data reproduction device ofclaim 1, wherein the audiovisual data reproduction device is configuredto store received files without executing any reception functions whenthe search returns no associated reception functions.
 10. Theaudiovisual data reproduction device of claim 1, wherein the types areselected from the group consisting of: song data type, graphics filedata type, video data type, advertisement data type, and survey datatype.
 11. The audiovisual data reproduction device of claim 1, whereinthe server is configured to send files to the audiovisual datareproduction device in response to a request from the audiovisual datareproduction device.
 12. A method of operating an audiovisual datareproduction device that is connected to a server via a networkconnection to a server, the server being configured to distribute filesto the audiovisual data reproduction device, the audiovisual datareproduction device comprising an operating system configured to managethe audiovisual data reproduction device, a storage medium; and aplurality of reception functions associated with respective types ofdata, the method comprising, in connection with the operating system:creating files in available storage areas of the storage medium of theaudiovisual data reproduction device to store files sent by the server,at least some of the files sent by the server indicating types of dataassociated with the respective files; for the files sent by the serverthat indicate the types of data associated with the respective files,searching for respective reception functions based at least in part onrespective indicated types; and when respective reception functions arefound, processing associated files that have been received and causingthe audiovisual reproduction device to be updated according to dataincluded in the processed received file.
 13. The method of claim 12,wherein indications of the types of data in the files sent from theserver are indicated by respective file extensions.
 14. The method ofclaim 12, wherein indications of the types of data in the files sentfrom the server are indicated by respective names of the files.
 15. Themethod of claim 12, wherein indications of the types of data in at leastsome of the files sent from the server correspond to song files, andfurther comprising causing a song database stored on the audiovisualdata reproduction device to be updated.
 16. The method of claim 12,wherein indications of the types of data in at least some of the filessent from the server correspond to song files, and further comprisingfor such files causing a compatibility check between versions of thesong files received and a version of the operating system of theaudiovisual data reproduction device, in connection with the respectivereception function.
 17. The method of claim 12, wherein indications ofthe types of data in at least some of the files sent from the servercorrespond to song files, and further comprising for such files causingan update to a statistics table used in determining selectionfrequencies of the songs corresponding to the files, in connection withthe respective reception function.
 18. The method of claim 12, whereinindications of the types of data in at least some of the files sent fromthe server correspond to song files, and further comprising for suchfiles causing an update to a purchase table including numbers and namesof all songs purchased for the audiovisual data reproduction device, inconnection with the respective reception function.
 19. The method ofclaim 12, wherein the audiovisual data reproduction device is configuredto store received files without executing any reception functions whenthe search returns no associated reception functions.
 20. The method ofclaim 12, wherein the types are selected from the group consisting of:song data type, graphics file data type, video data type, advertisementdata type, and survey data type, and wherein the server is configured tosend files to the audiovisual data reproduction device in response to arequest from the audiovisual data reproduction device.